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QO (54) Title: METHODS AND APPARATUS FOR VERIFYING THE PRESENCE OF INTENDED EMAIL ATTACHMENTS 

r- 

(57) Abstract: An email application program which executes on a host computer which transmits email messages includes routines 
2 for ensuring that email attachments which are intended to be transmitted witii the email messages are actually attached at the time 
of transmission. The content of the email message is processed to determine if the character string including the letters "attadi** are 
imbedded within the text of the message composed by the sender. If those characters are present, but no file has been designated by 
^ the sender for attachment to the outgoing email message, a warning is issued to advise the sender that intended email messages may 
^ not have been deagnated. 



■J 



wo 01/27828 PCrAJS«M27426 

PCX Patent Specification 

Xitlej Methods and Apparatus for Verifying Presence 

of Intended Email Attachments 



Applicant and Inventor: Mr. James Logan 

81 Castle Hin Road 
Windham, NH 03087 

Technical Field 

This invention relates to electronic mail systems and more particularly to methods and 
apparatus for ensuring that attachments to outgoing enwil messages are actually transmitted 
with such messages as intended by the sender. 

5 

Background Art 

Under early hitemet practices and standards, email transmissions were limited to 
character data usmg the ASCH character set To make it possible to send other types of data, 
the MIME (Multi-purpose Internet Mail Extensions) standard, as well as other techniques, 

10 were adopted to extend the capabiUties of emaO to transmit text in character sets other tfian 
US-ASCII, as well binary data, in multi-part messages which include "attachments." Using 
these techniques, files of data can be "attached" to outgomg messages, aUowing the sender to 
send graphics files, spreadsheets, word processing documents, executable programs, and any 
other kind of file to a desired email destination. 

1 5 The software infrastructure used to send files as email attachments is largely hidden 

from the user. Email application programs such as Eudora, Netscape Messenger and 
Microsoft's Outlook Express provide menu functions which make it easy for a sender to 
identify one or more files which are to be attached to an outgoing message. Usmg such 
programs, a sender typically types the message body, indicates the email address of intended 

20 recipient(s) and, if desired, uses a convenient "dialog box" mechanism displayed by the 

^plication program to identify any additional files which are to be sent as attachments to the 
outgoing email message. 

1 
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All too often, however, in the course of providing destination email addresses, adding 
subject headings, and handling other distractions, the sender will simply forget to "attach" files 
which he or she intends to send along with the email message. Since the body of the message 
typically makes it clear that an attachment was to be sent by including a comment such as 
5 "I've attached a copy of our current business plan for your review," the recipient will typically 
be aware that an intended attachment was not included, but must send a reply message 
requesting that the attachment be provided in a new messaged The fiailure to send intended 
attachments leads, at best, to undesirable delays which can have serious consequences when 
rapid communication of key information is important. 

10 

Summary of the Present Invention 

It is an object of the present invention to help ensure that email attachments are in fact 
attached to the email messages they are intended to accompany. 

hi a principal aspect, the present invention takes the form of methods and apparatus for 

1 5 scanning the text of an outgoing email message to identify character strings such as "attached " 
"attaching," and "attachment" which tend to detect the probable intent by the user to include 
an attachment vsdth the email message. If no attachment has in fact been identified for 
inclusion within an outgoing message that includes such text, the sender is informed by a 
suitable warning display or like before the email message is sent, affording the sender the 

20 opportunity to correct the deficiency by adding the intended attachment, so that the complete 
message and the desired attachment(s) are transmitted as intended. 

The preferred embodiment of the invention takes the form of an email messagmg 
system in which a first host computer operates as an email message source, a second host 
computer which operates as an email message destination, and a communications network 

25 such as the Internet provides a data pathway between said first and second computers. An 
email implication program executes on said first host computer for transmitting email 
messages via said communications network to said second host computer. A first routine 
executable under the control of tiie application program accepts die text of an ou^oing email 
message from a user. A second routine executable under tiie control application program 

30 before tiie message is sent allows tiie user to designate the filename of at least one file 

accessible to the first computer which is to be transmitted as an attachment to the text of the 
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outgoing email message. A third routine executable under the control of the application 
program before the outgoing message is sent processes the message text entered by the user to 
identify the presence of character strings in said text, such as " attaching," "attached," or 
"attachment" ," which tend to indicate that said user intended to (but may have failed to) 

5 designate at least one file as an attachment. A fourth routme executable under the control of 
said application program before the outgoing message is sent generates a warning to the user 
when the third routine mdicates that said user intended to designate at least one file as an 
attachment when said second routine has not been performed at least once to actually 
designate the intended attachment file. 

1 0 Preferably, a fifth routine which is also executable under the control of said application 

program prior to the transmission of the outgoing file generates a special warning to the user 
when said third routine indicates that two or more files were intended to be attached (by 
searching for the character string "attachments") and when less than two files were in fact 
attached by the execution of the second routine. 

15 

Brief Description of the Drawings 

Fig. 1 is a flowchart illustrating the operation of a preferred embodiment of the 

invention. 

20 Detailed Description 

The present invention operates in a conventional Internet email environment and 
includes software routines that execute in combination with conventional email application 
programs which conform to and implement SMTP, the "Simple Mail Transfer Protocol." 

SMTP is the de facto standard for electronic mail transport across the Internet. When 

25 an e-mail message is sent, SMTP packages the message in an electronic envelope and relays it 
to its destination. SMTP was introduced in a series of Request for Comment documents 
(RFCs) which are available firom many sources on the Internet, notably RFC 772, 780, and 
788, with the base specification appearing in RFC 821 issued in 1982. Work continued on 
SMTP, however, and over the years its capabilities have been significantly enhanced. 

30 Important RFCs that cover extensions or otherwise discuss SMTP include: RFC 974: Mail 
Routing and the Domain System; RFC 1 123: Requirements for Internet Hosts - Application 
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and Support; RFC 1869: SMTP Service Extensions; and RFC 1870: SMTP Service Extension 
for Message Size Declaration. 

RFC 822 defined a message representation protocol specifying the format of message 
headers expressed in the US-ASCII character set, but left the message content, or message 
5 body, as flat US-ASCII text. RFCs 2045 through 2049 contain the current standards 

collectively called the Multipurpose Internet Mail Extensions," or MIME, which extends the 
format specification of email messages to allow for textual message bodies in character sets 
other than US- ASCII, an extensible set of different formats for non-textual message bodies, 
multi-part message bodies, and textual header information in character sets other than US- 
10 ASCII. MIME governs the preferred way in which attachments are represented within the 
content of an SMTP message body, but other attachment representations are sometimes used, 
including UUencode (Unix to Unix encoding) and numerous other attachment representations. 
For present purposes, however, MIME encoding may be taken as illustrative. 
MIME messages have a four part header for each part of the email: 
1 5 a MIME-Version header field, 

a Content-Type header field, 
a Content-Transfer-Encoding header field, and 
two additional header fields used to fiirther describe the data in a body. 
A MIME message attachment in the body of an SMTP message is illustrated by below:: 

20 

10606E5F645E 

Content-Type: image/ jpeg; name="sailsBG. jP9" 
Content-Transfer-Encoding: base64 

Content-Disposition: inline; f ilename="sailsB6. jpg" 
25 / 9 j / 4 AAQSkZ JRgABAQAAAQABAAD/ 2 wBDAAgGBgcGBQgHBwc JCQgKDBQNDAsLDBk 
SEw8UHRofHh0aHBwgJC4nICISIxwcKDcpLDAxNDQ0Hyc5PTgyPC42NDL/2wBDAQ 

kJCQwLDBgNDRgylRwh 

The scrambled characters seen in at the end of the example message text quoted above 
30 are the printable character representations of the base64 encoded binary information which 
form the content of the attached file (in this case, a binary image file which named 
"salesBG.jpg"). It is important to note that, even though the attachment itself is unreadable to 

:4 
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humans, the existence and nature of the attachment as part of the message is readily apparent 
from the header information which, in accordance with the MIME specification, allows the 
content to be decoded into its original form and saved as a persistently stored named file by the 

SMTP application that receives the incoming message. 
5 The present invention preferably operates in cooporation with an SMTP compliant 

email application program which executes on the host computer from which email 
transmissions are sent. Such programs typically include text entry and editing routines which 
permit the user to compose natural language text to be included in the body of an outgoing 
message, and to enter the email address(es) of intended recipients. Such email application 

10 programs also typically includes menu-activated routines which prompt the user to enter 
filenames, or browse the file directories of the host computer to identify the filenames, of one 
or more persistently-stored data files, the content of which is to be included as "attachment" 
data using the available mail protocol, such as those specified by the SMTP MIME extensions. 
The application program then combines the text of the body of the message with an encoded 

15 version of the attachment file or files in accordance with the specifications of the MIME 
protocol, or whatever other protocol is use for the transmission of message and attachments. 

As contemplated by the invention, when the user completes the text of the message and 
has designated a subject for the message and the email addresses of tiie recipients, and has 
fiirther designated all of the files to be attached to the message, the user typically issues a 

20 "send" command to the application program, typically by clicking on a "send button" 

displayed by the appUcation program's graphical user interface. This command to send the 
message along with any designated attachments triggers the operation of tiie routines 
contemplated by the invention which are illustrated by the flow chart appearing in Fig. 1 of tiie 
drawings. 

25 In response to tiie depression of tiie send button (or some equivalent command to 

transmit tiie message) as indicated at II , routines are executed which issue a warning when it 
is likely tiiat tiie user has foiled to designate intended attachments. It should be understood 
tiiat these routines can be executed at any time prior to transmission, but are most 
advantageously performed when tiie user has indicated, in some fashion, tiiat tiie message is 

30 ready for transmission. In environments in 'wWch messages are first composed and tiien saved 
for later transmission (when, for example, tiie user later establishes dial-up connection witii an 
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SMTP server), the application's "send buttotf * or the equivalent in fact indicates an instruction 
to save the file for later transmission. It is preferable that the routines to be desCTibed be 
performed as soon as the user indicates that the message is believed to be ready for 
transmission. It is preferable to check the presence of mtended attachments as soon as 

5 message composition is completed, when the intended content of the message (and the identity 
of files to be attached) is fresh in the mind of the user, however, it will be understood that 
missing attachments can be checked at any time prior to actual message transmission. 

In the illustrative embodiment depicted in Fig. 1 , before the message is transmitted a 
test is performed at 13 to determine if at least one attachment has been designated. When this 

10 test is implemented as part of the application program, one or more variables set during the 
course of designating attached files which are within the address space of and visible to the 
application program may be readily inspected to detennme the number of filenames designated 
as attachments to the subject message by the user. 

If no attachments have been designated, the routine at 1 5 is performed to scan the 

15 message text entered by the user of the application program to identify the presence of terms 
(character strings) which indicate an intent to include attachments with the message. 
Commonly, when attachments are included with a message, the nature of the attachments is 
explained in the body of the message using statements such as "I am attaching an Excel 
spreadsheet "The minutes of the meeting are attached . . "Attachment: January business 

20 plan", "The four files included as attachmaits to this message are: ..." Thus, a case- 
insensitive search for the character string " attach" (six letters with a leading space) as 
indicated at 1 5 would successfiilly identify any of the phrases noted above and thus indicate 
the user's mtent to designate attachment files as part of the outgoing message. 

If the character string " attach" was not found in the search at 15, the routine branches 

25 at 1 7 to direct the application program to send the message (or to place the message in a queue 
for fiiture transmission) as indicated at 20. If the character string " attach" was found when no 
files have been designated, the program branches at 17 to issue a warning at 19 informing the 
sender that attachment files have not yet been designated. If desired, a portion of the message 
text vAAch included the string " attach" might be repeated in a warning message display to 

30 indicate to the user the basis upon which the automatic warning was being generated. 
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The search, test and warning at 15, 17 and 19 do not properly account for an intent to 
attach more than one file when only one file is attached. This situation is handled by the test at 
23 in combination with the test at 13 which causes a search to be performed at 25 for the string 
"attachments". If that search indicates that more than one attachments may have been 
intended to be designated, when only one file has been designated, a branch is performed at 27 
to execute a routine for issuing a warning at 29 indicating that more than one attachments may 
be required. It may be noted that the search at 25 may be expanded to include a search for 
some fomi of " attach" in combination with the term "files" to identify phrases like "I have 
attached three files" which would not be identified by a search for "attachments". 

It is to be understood that the embodiment of the invention which has been described is 
merely illustrative of one application of the principles of the invention. Numerous 
modifications may be made by those skilled in the art to the implementations disclosed above 
without departing from the true spirit and scope of the invention. 
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What is claimed is: 

1 1 . The method for ensuring that an attachment, vsUch a sender intends to transmit 

2 along with the text of an outgoing email message, is actually transmitted with said outgoing 

3 mess^e, said method comprising, in combination, the steps of: 

4 prior to the transmission of said message, determining whether the sender of said 

5 message has designated a file as an attachment to be sent with said message, 

6 prior to the transmission of said message, processing the text of said message to 

7 identify the presence within said text of a character string indicating a likelihood that said 

8 sender intended to transmit one or more files as attachments to said message, and 

9 prior to the transmission of said message, producing a warning indication perceptible 

10 by said sender when said sender has failed to designate said file when said character string is 

1 1 identified in said text. 

1 2. The method set forth in claim 1 wherein said step of processing the text of said 

2 mess^e includes performing a case-insensitive search of at least a portion of said text for a 

3 character string including the characters ""attach". 

1 3. The method set forth in claim 1 wherein said outgoing message is generated with 

2 the aid of an email application program which includes means for enabling said sender to 

3 designate said file and wherein said step of determining whether the sender of said message 

4 has designated a file includes the step of evaluating a variable set by said application program 

5 when a file is designated as an attachment to an outgoing email message. 

1 4. The method set forth in claim 1 wherein said step of determining whether the sender 

2 of said message has designated a file consists of processing the content of said message to 

3 identify data therein which indicates the presence of at least one attachment. 

1 S. An email messaging system comprising, in combination, 

2 a first host computer which operates an email message source, 

8 
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1 a second host computer which operates as an email message destination, 

2 a communications network which provides a data pathway between said first and 

3 second computers, 

4 an message transmitting application program which executes on said first host 

5 computer for transmitting email messages via said communications network to said second 

6 host computer, 

7 a first routme executable under the control of said application program for accepting 

8 the text of an outgomg email message fi-om a user, 

9 a second routme executable under the control of said application program for accepting 

10 from said user a designation of the name of at least one file accessible to said first computer 

1 1 Mdiich is to be transmitted as an attachment to said outgoing email message, 

12 a third routine executable under the control of said application program for processing 

1 3 said text to identify the presence of character strings in said text tending to indicate that said 

14 user intended to designate at least one file as an attachment to said outgoing message, and 

15 a fourth routine executable under the control of said application program for generating 

16 a warning to said user when said third routine indicates that said user intended to designate at 

1 7 least one file as an attachment when said second routine has not been performed at least once 

1 8 for said outgoing message. 

1 6. An email messaging system as set forth in claim 5 wherein one of said character 

2 strings includes the letters "attach". 

1 7. An email messaging system as set forth in claim 5 further including a fifth routine 

2 executable under the control of said application program for generating a warning to said user 

3 when said third routine indicates that said user intended to designate more than one file as an 

4 attachment when said second routine has not been performed at least twice for said outgoing 

5 message 
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